Budapest Preface

ion is essential in any software reuse technique. As Wegner states, abstraction and reusability are two sides of the same coin [Weg83]. Krueger states that \without abstraction developers would be forced to sift through a collection of reusable artifacts trying to gure out what each artifact did, when it could be reused, and how to reuse it." [Kru92]. Raising abstraction levels is a major challenge in software engineering. The relation between abstraction and reuse gives a rst hint about the di culties we face in software reuse. Every software abstraction has two levels: speci cation (what is done by the abstraction) and realization (how is it done). The realization of one level of abstraction is the speci cation of the next lower level of abstraction. Every abstraction contains a hidden part (not visible in the speci cation), a xed part, and a variable part. The variable part maps into the collection of possible realizations. The creator of an abstraction can decide in which part to put certain information, e.g., the size of a stack could be variable, xed or hidden. The speci cation must contain all the information needed by the reuse of its realization. Finding concise abstractions for components is a di cult task. The bestknown successes are in application domains with application-speci c, oneword abstractions, e.g.: sine, matrix (in numerical analysis), stack, list (in abstract data types). 3.4.2 Compositional Reuse Compositional reuse is based on the idea of reusable components that (ideally) remain unmodi ed in their reuse. Higher-level or more complex components are built by combining lower-level or simpler components. Only if needed components are not available and cannot be created by modi cation of existing components are they built from scratch or constructed from lower-level components. The components suitable for reuse are collected in repositories. Compositional reuse is based on component repositories (e.g., function libraries) or on principles of organization and composition, like pipe architectures or the object-oriented construction of software systems. 3.4 Reuse Techniques 25 Component repositories. Successful reuse requires having a wide variety of high-quality components, proper classi cation and retrieval mechanisms, su cient and proper documentation of components, a exible means for combining components, and a means of adapting components to speci c needs. In an ideal scenario reused components are largely atomic and remain unmodied. However, often this ideal cannot be achieved and the components have to modi ed and changed in order to t the reusers' special needs. During composition components are regarded as passive elements that are combined by prede ned principles which are crucial for systems being built from existing components. Today, the nature of a reusable component technology strongly depends on the programming languages used. Components can be reusable functions, e.g., statistics libraries, numerical libraries, or packages, modules, subsystems and classes. The latter can include data-centered artifacts like abstract datatypes. Challenges in the context of repositories are techniques to locate components e ciently, e.g., classi cation schemes, retrieval techniques, and to integrate them in software systems. This leads to the next aspect of compositional reuse, component composition. Chapter 14 provides more details on repositories and classi cation schemes. Component composition. Software components exist in many di erent forms. They cannot be arbitrarily assembled and expected to communicate and cooperate. In order to enable the combination of components they must rely on the same kind of composition technique. Module interconnection languages and the Unix pipe mechanism are examples of possible composition of reusable components. The Unix pipe mechanism is one of the well-known examples of a simple, yet powerful composition and integration technique where complex programs can be built out of simpler ones. The alliance of components is accomplished by connecting the output of one component to the input of another [Ker84]. Incompatibilities of components are among the main hindrances of successful component reuse. In Chapter 7 we deal with di erent forms of composition and interoperation and describe composition mismatches. Code and design scavenging. Scavenging fragments from existing software systems and using them as part of new software development is an ad-hoc and unsystematic, although e ective approach to reusing software system designs and source code [Kru92]. In this scenario reused components are fragments taken from various locations of other systems rather than selfcontained, tested and documented components from a repository. Nevertheless, it is a kind of composition, and experienced programmers can gain high productivity increases. We distinguish between code and design scavenging: { Code scavenging Blocks of source code are copied from an existing system. 26 3. Technical Aspects of Software Reuse { Design scavenging Large blocks of code are copied. Many of the internal details are deleted. The global template of the design is retained. There is no abstraction involved in scavenging. The developer is forced to become closely involved with implementation details of the reused fragments. 3.4.3 Generative Reuse Generative reuse is based on the reuse of a generation process rather than the reuse of components. Large frame structures are used as invariants, i.e., reused without change. Variant functionality must be added to customize the invariant parts. The components that are reused are not concrete and self-contained as in the compositional approach. The parts to be reused are incorporated into a program that generates reusable patterns. Typical examples of this kind of reuse are generators for lexical analyzers, parsers, and compilers (e.g., lex and yacc on the Unix platform), conventional application generators (e.g., fourth-generation languages), expert system generators, and structure-oriented editor generators. Generators that synthesize software from reuse libraries to construct systems for a target domain compose prefabricated, interchangeable components and thus contain compositional aspects also (see Batory et al. [BST94]). Subsequently, we distinguish between application generators, language-based generators, and transformation systems. Programming languages can be seen as low level speci cation languages. This is brie y sketched at the end of this section. Application generators. Application generators reuse complete software system designs. They are appropriate in application domains where [Kru92]: { many similar software systems are written, { one software system is modi ed or rewritten many times during its lifetime, and/or { many prototypes of a system are necessary to converge on a usable product. Application generators allow inexperienced people to generate customized applications. In application generators, reusable patterns exist in the generator itself in the form of source code. Application generators currently provide only small coverage for software development. But the focus on narrow domains is also an advantage. Highly productive creation of quality commercial software with application generators has been reported [Lev86]. A survey of application generators is given by Horowitz et al. [HKN85]. Language-based generators. Language-based generators provide a speci cation language that represents the problem domain and simultaneously hides implementation details from the reuser. Speci cation languages allow developers to create software systems using constructs that are considered 3.4 Reuse Techniques 27 high-level relative to programming languages [Kru92]. They are also known as executable speci cation languages. Speci cation languages help in reusing implementation patterns of programming languages, similar to programming languages that help in reusing assembler patterns. These languages typically have mathematical abstractions that are not widely used in the conventional software life cycle. Speci cation languages are used to describe abstract speci cations, from which executable programs are automatically generated. Language-based generators di er from application generators mainly in that they use general-purpose, application-independent abstractions rather than application-speci c ones. The primary concern is development and modi cation e ciency rather than high execution speed. This may eliminate them as development vehicles for various of today's production systems, but they can be used as a basis for rapid prototyping and validation of software systems. The Setl optimizer is an example of this kind of generation [DFSS89]. It is based on representing computations as operations on mathematical sets. Transformation systems. With transformation systems, software is developed in two phases: describing the semantic behavior of a software system and applying transformations to the high-level speci cations. For example, abstract programs are transformed into their concrete counterparts in an approach described by Cheatham [Che89]. Martin distinguishes the subcategories skeleton approach, kitchen sink approach, parameterized approach, and stepwise re nement approach [Mar90]: { Skeleton approach In the skeleton approach, the reuser starts with a generic application skeleton and lls in details and missing parts. The generic part may cover many aspects of an application, e.g., user interface details or event handling. { Kitchen sink approach The kitchen sink approach works the other way around. The reuser starts with a detailed and extensive framework and prunes parts away that are not needed for the current application. { Parameterized approach The parameterized approach provides certain parameters to modify the resulting software. { Stepwise re nement approach In the stepwise re nement approach, reusers re ne the software's behavior in incremental steps. The Draco system generates applications from domain-oriented speci cations [Nei89]. It can be regarded as application generator and as transformation system that use patterns within transformation rules. 28 3. Technical Aspects of Software Reuse Programming languages. Programming languages such as C, C++ and Ada are usually not treated as examples of software reuse. But their goals and achievements have strong parallels to the current-day aspirations of software reuse researchers [Kru92]. In the same way as we regard language-based generators, application generators, and transformation systems in the context of software reuse, with programming languages we do not reuse software itself, but rather we reuse language patterns. The artifacts to be reused are assembly language patterns. Of course, these languages provide only a relatively low level of abstraction. However, they provide a factor of 5 speedup in writing source code [Bro75]. As with generators, programmers use variant and invariant parts of the abstraction and do not have to worry about all the assembly language details that are actually reused. The compiler provides the transformation from the speci cation (programming language) to the implementation (assembly or machine language). 3.4.4 Generation vs. Composition Generation-based systems have the advantage that the reused patterns can be designed and implemented carefully by experienced programmers. But they are applicable only to a certain domain and are typically restricted to the reuse of source code. Also, they cannot be applied easily in all situations. Often they are too general or to speci c for applications under consideration. Components are applicable to a wider variety of applications. Additionally, they are more modular and self-contained and thus maintainable. Their disadvantage is that they are seldom perfect or general enough. This might lead to many modi cations, which reduces productivity gains and can lead to immense numbers of components in repositories. Table 3.2 summarizes the comparison of compositional and generative reuse (see Biggersta and Richter [BR89]). Compositional reuse provides the more general approach. The generative approach is useful in speci c domains and can be built on top of components. 3.5 Reuse Intentions Depending on whether the internals of a software component are visible to reusers we speak of black-box or white-box reuse. If a component is a black box we cannot modify its internals: we use it as is. White-box components are usually modi ed, even though this is not necessarily the case. They o er both as-is reuse and reuse by adaptation. The term glass-box reuse means white-box visibility but black-box reuse. 3.5 Reuse Intentions 29 Table 3.2. Compositional reuse vs. generative reuse Reuse technique Composition Generation Reused component building blocks patterns Nature of component atomic and immutable, passive di use and malleable, active Emphasis component repositories, composition principles, (code/design scavenging) application generators, language based generators, transformation systems Examples function/class libraries, Unix lters parser generators, 4th generation languages 3.5.1 Black-Box Reuse Reusing a component as a black box means using it without seeing, knowing or modifying any of its internals. The component provides an interface that contains all the information necessary for its utilization. The implementation is hidden and cannot be modi ed by the reuser. Thus reusers get the information about what a component is doing, but they do not have to worry about how this is achieved. The implementation can be changed without any e ects on reusers. Usually a black box is reused as-is. Object-oriented techniques allow modi cations of black boxes by making modi cations and extensions to a component without knowing its internals. This is one of the major contributions of object-oriented programming to software reuse. However, components have to be designed so that such modi cations become viable. 3.5.2 White-Box Reuse White-box reuse is the typical case in the unplanned ad-hoc reuse that is still widespread today. It means reuse of components of which internals are changed for the purpose of reuse. White boxes are typically not reused as is, but by adaptation. They create more opportunities for reusers due to the ease of making arbitrary changes. On the negative side of white-box reuse, it requires additional testing and costlier maintenance. Unlike black boxes, a new component derived by modi cations to an existing component must be regarded as a new component and thoroughly tested. Additionally, the new component requires separate maintenance. If many copies of a component exist with slight modi cations, it becomes burdensome to x errors that 30 3. Technical Aspects of Software Reuse a ect all of them. If the changes made to a component are only minor, e.g., a few variable renamings or changes in procedure calls, the term grey-box reuse is also used. 3.5.3 Glass-Box Reuse The term glass-box reuse is used when components are used as-is like black boxes, but their internals can be seen from outside (see Goldberg and Rubin [GR95]). This gives the reuser information about how the component works without the ability to change it. But this information may be crucial for understanding how certain tasks are carried out. It may also give the reuser some con dence from being able to see inside the component and capture how it works. Additionally, getting internal information provides some kind of knowledge transfer and, for example, can help in building new components. Glass-box reuse has its negative sides. It may lead to dependencies on certain implementation details which become fatal when the internals of the component are changed. Unfortunately, giving reusers detailed information about a component's internals often serves as compensation of nonexistent or insu cient documentation. 3.5.4 Generative Reuse Generative reuse is itself a reuse technique, but it can be seen as kind of blackbox reuse [GR95]. Instead of picking one of several existing black boxes, a component's speci cation is created and its implementation automatically generated by a program generator. The program generator is a black box; its internals are of no interest to the reuser. Also, the generated implementation will not be modi ed. If changes are necessary, they will be made in the speci cation and the implementation is recreated. (In practice, however, modi cations to the generated implementation are sometimes made due to shortcomings in the generator.) 3.5.5 Black-Box vs. White-Box Reuse Black box reuse is more di cult to achieve than white-box reuse but promises higher quality and reliability of the resulting software system. The potential of customizing black-box components can increase their reuse potential but has to be carefully considered and designed. Black-box components have the advantage of possible veri cation and certi cation. Even though we are far from having a market of veri ed and certi ed components, such attributes will become essential in the future. 3.6 Reuse Products 31